https://modernanalyst.com RSS feeds for Business Analyst Community & Resources | Modern Analyst 60 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6675/Happy-Alternate-and-Exception-Paths-are-Applicable-to-More-Than-Just-Use-Cases.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=6675 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6675&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6675/Happy-Alternate-and-Exception-Paths-are-Applicable-to-More-Than-Just-Use-Cases.aspx The concepts of Happy, Alternate, and Exception Paths originated with Use Cases, but turn out to be applicable to any graphical modelling technique that depicts Flow. This article presents examples of Business Process, Activity, and State Transition diagrams with these concepts represented simply using the common “Traffic Light” colors green, amber, and red. The benefits to both business analysts and stakeholders are discussed. adrian Mon, 03 Feb 2025 03:05:00 GMT f1397696-738c-4295-afcd-943feb885714:6675 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6489/Use-Cases-The-Business-Analysts-Best-Friend.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=6489 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6489&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6489/Use-Cases-The-Business-Analysts-Best-Friend.aspx I like use cases. There, I said it, and I’m not sorry. Use cases have fallen out of fashion in recent years, being largely replaced by user stories on agile projects. The two techniques can coexist and complement each other, however.  Use cases offer several advantages that user stories lack. This article describes some of the many benefits that use cases can provide and why every business analyst (BA), product owner (PO), and software development team should include them in their tool kit. Transform VA Mon, 02 Sep 2024 06:53:00 GMT f1397696-738c-4295-afcd-943feb885714:6489 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6490/When-Use-Cases-Arent-Enough-Event-Analysis.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=6490 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6490&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6490/When-Use-Cases-Arent-Enough-Event-Analysis.aspx Although use cases are valuable for many projects, sometimes event analysis is a more effective requirements elicitation technique. Valuable as they are, use cases aren’t the ideal tool for every type of product. A complementary requirements elicitation strategy is to explore the various events that a system or product could experience and how it should respond to each of them. The response depends on what state the system is in when it detects the event. Event analysis is particularly well-suited for middleware products and real-time systems that include both software and hardware components. Transform VA Sun, 21 Apr 2024 21:12:00 GMT f1397696-738c-4295-afcd-943feb885714:6490 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6093/User-Stories-vs-Use-Cases.aspx#Comments 5 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=6093 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=6093&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/6093/User-Stories-vs-Use-Cases.aspx What is Use Case? Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb. A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether. What is User Story? User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board. Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases. Transform VA Sun, 07 Aug 2022 08:37:00 GMT f1397696-738c-4295-afcd-943feb885714:6093 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5720/Handling-CRUD-in-your-Use-Cases.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5720 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5720&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5720/Handling-CRUD-in-your-Use-Cases.aspx So how do you handle CRUD in your use cases? Please don’t confuse CRUD with CRAP in your use cases. That’s a lot harder to deal with and requires a conversation with your subject matter experts (SMEs). CRUD is an acronym for Create, Read, Update and Delete. It describes the lifecycle in the maintenance of system data, whether that data is stored in a database or is file based data stored in a document management system like SharePoint. Transform VA Sun, 08 Nov 2020 05:24:00 GMT f1397696-738c-4295-afcd-943feb885714:5720 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5585/Use-Cases--The-New-School.aspx#Comments 5 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5585 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5585&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5585/Use-Cases--The-New-School.aspx In the world of software development Use Cases are one of many very powerful techniques often used these days.  Use cases describe how a person or a system interacts with the solution being modeled/built to achieve a goal. Basically, it’s a step by step explanation of what a user can do and how the solution must respond. As any other business analysis technique, use cases have their advantages and disadvantages. One of the main disadvantages of use cases is that this technique is not graphical – a use case diagram is but use case descriptions are not, and use case descriptions really lack of visualization especially if there are multiple alternative flows and exception flows that branch out and then loop back into the main one. adrian Mon, 20 Apr 2020 02:03:00 GMT f1397696-738c-4295-afcd-943feb885714:5585 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5465/Generalization-Specialization-Use-Case-Diagrams-and-Scenarios.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5465 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5465&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5465/Generalization-Specialization-Use-Case-Diagrams-and-Scenarios.aspx Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios for a future gas station business. Transform VA Sun, 05 Jan 2020 20:00:00 GMT f1397696-738c-4295-afcd-943feb885714:5465 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5144 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5144&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they’re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process. What makes requirements an essential part of a BA’s job? For a business analyst, requirements are defined as the logical and essential steps which needs to be fulfilled in order to achieve a successful end-state or a solution to a stakeholder’s business problem. These requirements drive the solution and are the key elements of any successful solution implementation. Business analysts are the ones who not only ensures the expected solution is delivered, but they’re also the owner of the requirements handling/management process. Business analysts identify the right requirements and help them convert into a form consumable by delivery teams to deliver the expected outcome in a timely manner. The requirements management/handling process consists of 4 basic steps: Discovery, Analyze, Draft and Implement. 1.     Discovery Requirements discovery is a phase in which we identify, gather and scope the requirements. This phase builds the basic requirements framework for delivery. To identify and gather requirements, a business analyst uses various requirements elicitation techniques like observation, shadowing, protocol analysis, apprenticeship, prototyping, focus groups, scenario’s, background research and many others. These techniques are aimed towards gathering information related to a business problem and/or a solution that business stakeholders are trying to achieve. Requirements identification is a highly interactive activity, which relies on the involvement of the right stakeholders. Elicitation activities continue while a business analyst traverse through other stages/steps of requirements gathering. It is very important for a business analyst to not only identify but to scope the requirement. Requirements are driven by information collected by various elicitation methods; however, the relevancy of the requirement needs to be determined. The simplest way to do so is to perform some of the elicitation techniques repetitively. Look for facts via secondary support of documents or information from another source just to verify. Chart your scope based on the overall direction of the information flow and the end-state which stakeholders are trying to achieve. Scoping cannot be definitive in the business analyst’s landscape. It’s a loose boundary which needs to be flexible enough to account for other business or priority changes. Loose boundaries do help the business analyst in defining a playground where they need to operate for a successful outcome. 2.     Analyze The most important activity of the requirements handling process is to analyze a requirement. Analyzing a requirement will provide us with a definite outcome along with the complete information on achieving that outcome. There can be various types of analysis like strategic analysis, functional and technical analysis. Strategic analysis is performed by understanding the strengths, weakness, opportunities and threats provided by implementing this requirement. It helps a business analyst to understand the priority and criticality of the requirement which also determines how essential it is for a business to implement those requirements. Functional analysis provides an ability to understand the requirement from the end user perspective.  It is performed by interacting with people who’re impacted by the implementation of requirements. This provides unique opportunity for a business analyst to shape the solution in a way that accommodates the minimal, easy to adapt change to the end users or the impacted. Technical analysis is performed by further breaking down functional requirements into a series of small implementation steps which a delivery person can understand. It is the delivery person/team who needs to deliver the technical solution. It is important to not miss any aspect of functional requirement to be translated into technical requirements which is a supporting pillar for successful solution implementation. Depending upon the type of analysis, we determine the type of requirement. Upon successfully analyzing and understanding the type of requirement we start drafting requirements into various artifacts. 3.     Draft Once a business analyst has understood the type of requirements and its expected outcome, business analyst can draft those requirements in their respective artifacts. There’re various artifacts such as business requirements document and/or specification requirements document and user stories which are authored and owned by a business analyst while there’re some other like project charter, technical design document or anything alike to which a business analyst contributes actively. Drafting of requirements take the utmost time as the translation needs clarifications and numerous back and forth interactions. Once a requirement drafting is complete, it’s time to walk them through with the entire team. 4.     Implement The first step of requirements implementation is to arrange for a walk-through of freshly drafted requirements where the audience includes all stakeholders including delivery team. This walk-through session helps with course correction of requirements if there’s a miss while drafting them. Also, requirements walkthrough is a common platform where in the stakeholders and other team members have the opportunity to ensure alignment of the requirements to the desired end state. Once the requirements are defined and finalized, business analysts have to ensure continuous requirement refinement for successful delivery. This is the final step of requirements management process. Once the requirement has been identified, scoped, analyzed, drafted and confirmed, business analysts have to keep their eye out for on-going business changes, these changes may affect any of the existing requirements and their desired outcomes. As business changes are constant, the impacts on the already drafted requirements is constant. There is a small deviation of requirements which can still be managed by refining the requirement and updating them, but then if the deviation requires additional effort for which the cost involved is high, then changes are to be considered for enhancement. This decision must be evaluated by a business analyst before taking appropriate actions accordingly. At this stage, all the requirements are the guiding principle for the delivery team to deliver the solution. Requirements Handling/Management Process is the one, a business analyst has to master to be considered as successful. Author: Nimil Parikh, Business Analyst Nimil Parikh is a new generation business analyst who transforms business processes by leveraging IT tools and applications. He has over 7 years of experience modeling, analyzing, measuring, improving, optimizing and automating business processes. He adds value by his ability to context switch while providing cross-functional business solution and ensuring timely delivery by managing and streamlining business processes and driving strategic leadership. He is known to introduce IT business transformation and ensure successful implementation. Nimil possess MBA from San Jose State university, MBA Marketing and Information technology engineering from India. Nimil lives in Campbell, California. He enjoys challenges and believes in making things right. Reach him via email – parikhnimil@yahoo.co.in   Nimil Parikh Sun, 21 Oct 2018 21:22:00 GMT f1397696-738c-4295-afcd-943feb885714:5144 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3658/Use-cases-or-business-process-maps-what-technique-to-use.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3658 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3658&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3658/Use-cases-or-business-process-maps-what-technique-to-use.aspx A list of business analysis techniques is pretty extensive and from year to year new techniques appear, or become more formalised, and are adopted by business analysts all over the world. Some techniques become more popular and are widely used and some are used rare or only when a specific need arises. But definitely there are techniques that became very popular and are used on a daily basis and even become buzz words for some people. These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use. Transform VA Mon, 07 Nov 2016 01:50:00 GMT f1397696-738c-4295-afcd-943feb885714:3658 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2016/End-to-End-UML-Use-Case-Specification.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2016 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2016&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2016/End-to-End-UML-Use-Case-Specification.aspx A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written. speeditonline Mon, 25 May 2015 13:40:00 GMT f1397696-738c-4295-afcd-943feb885714:2016 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2927/When-Use-Cases-Arent-Enough-Part-3.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2927 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2927&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2927/When-Use-Cases-Arent-Enough-Part-3.aspx Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer. Transform VA Sun, 15 Mar 2015 23:20:00 GMT f1397696-738c-4295-afcd-943feb885714:2927 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2925/When-Use-Cases-Arent-Enough-Part-2.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2925 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2925&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2925/When-Use-Cases-Arent-Enough-Part-2.aspx It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't. Transform VA Sun, 11 Jan 2015 22:10:00 GMT f1397696-738c-4295-afcd-943feb885714:2925 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2931/When-Use-Cases-Arent-Enough-Part-1.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2931 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2931&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2931/When-Use-Cases-Arent-Enough-Part-1.aspx The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem. Transform VA Mon, 01 Dec 2014 01:10:00 GMT f1397696-738c-4295-afcd-943feb885714:2931 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3116/Use-Case-Fragments.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3116 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3116&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3116/Use-Case-Fragments.aspx A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use? adrian Fri, 14 Nov 2014 08:08:00 GMT f1397696-738c-4295-afcd-943feb885714:3116 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2952/Anatomy-of-a-Use-Case-Skip-the-Outline-and-Dive-into-the-Main-Scenario.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2952 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2952&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2952/Anatomy-of-a-Use-Case-Skip-the-Outline-and-Dive-into-the-Main-Scenario.aspx This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels. Transform VA Sun, 26 Oct 2014 11:31:00 GMT f1397696-738c-4295-afcd-943feb885714:2952 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2788/Verifying-Use-Cases-Data-Flow-Diagrams-Entity-Relationship-Diagrams-and-State-Diagrams-via-State-Linkages.aspx#Comments 4 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2788 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2788&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2788/Verifying-Use-Cases-Data-Flow-Diagrams-Entity-Relationship-Diagrams-and-State-Diagrams-via-State-Linkages.aspx The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements. Transform VA Mon, 10 Mar 2014 09:32:00 GMT f1397696-738c-4295-afcd-943feb885714:2788 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2835/Why-Dont-Use-Cases-Just-Go-Away.aspx#Comments 22 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2835 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2835&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2835/Why-Dont-Use-Cases-Just-Go-Away.aspx Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are. Discussed, dissected, blogged about—why don’t they just go away?!  Transform VA Mon, 20 Jan 2014 03:01:00 GMT f1397696-738c-4295-afcd-943feb885714:2835 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2017/End-to-End-UML-Use-Case-Diagram.aspx#Comments 4 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2017 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2017&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2017/End-to-End-UML-Use-Case-Diagram.aspx Use case diagrams are used to show the decomposition of a business problem or software solution into a set of discrete functions (the use cases) which can be enacted by or on behalf of users (the actors). In a nutshell, this diagram shows who (the actors) can do what (the use cases) when interacting with the software solution. speeditonline Sun, 04 Aug 2013 22:25:00 GMT f1397696-738c-4295-afcd-943feb885714:2017 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2648/Developing-Effective-Agile-Requirements-Relies-on-Both-User-Stories-and-Use-Cases.aspx#Comments 4 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2648 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2648&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2648/Developing-Effective-Agile-Requirements-Relies-on-Both-User-Stories-and-Use-Cases.aspx As the Agile movement continues to gain momentum and managing projects using Agile methods becomes more and more prolific, project professionals must become more savvy in their use of Agile methods. While the techniques and processes associated with Agile are different than those associated with Waterfall, many innovative project teams are incorporating non-Agile techniques into the Agile environment, with great success. Transform VA Mon, 17 Jun 2013 01:20:00 GMT f1397696-738c-4295-afcd-943feb885714:2648 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2181/Building-the-Security-Model-with-Use-Case-and-Class-Models.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2181 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2181&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2181/Building-the-Security-Model-with-Use-Case-and-Class-Models.aspx In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges.  This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models Transform VA Mon, 11 Jun 2012 05:05:00 GMT f1397696-738c-4295-afcd-943feb885714:2181 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2071/Document-Decisions-Separately-and-Explicitly-A-Proposed-Use-Case-Scenario-Best-Practice.aspx#Comments 9 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2071 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2071&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2071/Document-Decisions-Separately-and-Explicitly-A-Proposed-Use-Case-Scenario-Best-Practice.aspx This article proposes a use case best practice technique: Always document decisions separately and explicitly in use case scenarios. This practice assists the business analyst in identifying where alternate and exception paths may be needed.This is similar to how decisions and resulting gateways are documented in Business Process Model and Notation (BPMN). Transform VA Tue, 17 Jan 2012 10:47:00 GMT f1397696-738c-4295-afcd-943feb885714:2071 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2012/Putting-Systems-Analysis-Into-Context-using-the-Context-Diagram.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2012 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2012&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2012/Putting-Systems-Analysis-Into-Context-using-the-Context-Diagram.aspx This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram. speeditonline Tue, 20 Sep 2011 00:48:00 GMT f1397696-738c-4295-afcd-943feb885714:2012 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1905/Use-Case-Points-an-analysis-phase-estimating-technique.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1905 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1905&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1905/Use-Case-Points-an-analysis-phase-estimating-technique.aspx Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases. speeditonline Mon, 01 Aug 2011 04:03:00 GMT f1397696-738c-4295-afcd-943feb885714:1905 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1713/The-Structure-of-Business-Analysis-Documents.aspx#Comments 7 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1713 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1713&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1713/The-Structure-of-Business-Analysis-Documents.aspx The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a Business Analyst and the main sections they contain. These are the main documents produced by a BA over the course of a project...   AlexK Mon, 28 Feb 2011 05:09:00 GMT f1397696-738c-4295-afcd-943feb885714:1713 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1442/Use-Cases-and-Business-Rules-Can-They-Work-Together.aspx#Comments 28 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1442 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1442&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1442/Use-Cases-and-Business-Rules-Can-They-Work-Together.aspx There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.   speeditonline Mon, 09 Aug 2010 04:48:00 GMT f1397696-738c-4295-afcd-943feb885714:1442 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1217/From-Research-to-Implementation-Use-Case-Diagrams-Usage-and-Benefits.aspx#Comments 10 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1217 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1217&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1217/From-Research-to-Implementation-Use-Case-Diagrams-Usage-and-Benefits.aspx Some people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still linger in the minds of many Business Analysts... adrian Mon, 04 Jan 2010 05:23:00 GMT f1397696-738c-4295-afcd-943feb885714:1217 https://modernanalyst.com/Resources/Articles/tabid/115/ID/880/Use-Case-Recycling-by-Extracting-Business-Rules.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=880 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=880&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/880/Use-Case-Recycling-by-Extracting-Business-Rules.aspx Have you ever thought the following thought while describing business processes? A decent percentage of the work business analysts (BAs) do is repetitive in nature. Business rules define the various subject matters, different businesses, or just differences in doing business. Just recently, I have again used a use case approach to a business process reengineering (BPR) problem. The aim was restructuring along natural business module borders, so that different applications (new and existing ones) can handle the business process more efficiently, more secure and within the right stakeholder's responsibilities. As almost always, documentation of the business processes had undergone aging as well. adrian Thu, 26 Mar 2009 09:02:00 GMT f1397696-738c-4295-afcd-943feb885714:880 https://modernanalyst.com/Resources/Articles/tabid/115/ID/889/How-to-REALLY-engage-your-stakeholders-during-use-case-modeling.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=889 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=889&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/889/How-to-REALLY-engage-your-stakeholders-during-use-case-modeling.aspx In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly. In particular, I'll be mentioning storyboards, wireframes and prototypes. I'll also cover what level of quality and detail you should adopt when applying these techniques. alex_papworth Sat, 21 Mar 2009 17:30:00 GMT f1397696-738c-4295-afcd-943feb885714:889 https://modernanalyst.com/Resources/Articles/tabid/115/ID/620/UML--Business-Context.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=620 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=620&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/620/UML--Business-Context.aspx “Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system. In this article we’ll take a brief look at which of the 13 diagrams are of most relevance for us and how they fit together... Author: Jan Kusiak pddean Tue, 02 Dec 2008 02:04:00 GMT f1397696-738c-4295-afcd-943feb885714:620 https://modernanalyst.com/Resources/Articles/tabid/115/ID/609/Complex-Requirements-On-an-Agile-Project.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=609 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=609&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/609/Complex-Requirements-On-an-Agile-Project.aspx The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community. The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements. Author: Scott Ambler adrian Sat, 08 Nov 2008 22:10:00 GMT f1397696-738c-4295-afcd-943feb885714:609 https://modernanalyst.com/Resources/Articles/tabid/115/ID/477/Tracing-Corporate-Strategy-to-a-Line-of-Code.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=477 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=477&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/477/Tracing-Corporate-Strategy-to-a-Line-of-Code.aspx One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy.  host Tue, 08 Jul 2008 02:00:00 GMT f1397696-738c-4295-afcd-943feb885714:477 https://modernanalyst.com/Resources/Articles/tabid/115/ID/194/What-Are-Use-Case-Studies.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=194 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=194&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/194/What-Are-Use-Case-Studies.aspx A use case study is designed to describe a situation in which the program is being utilized by the end user. It will tell a story of sorts describing how the program works and the input of the user. It does not tell how the program was developed. The details of the programming are not included in the use case study. You are trying to express the concept behind the creation. Author: Tony de Bree admin Tue, 20 Nov 2007 06:55:00 GMT f1397696-738c-4295-afcd-943feb885714:194 https://modernanalyst.com/Resources/Articles/tabid/115/ID/168/From-Use-Case-Diagrams-to-Context-Diagrams.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=168 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=168&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/168/From-Use-Case-Diagrams-to-Context-Diagrams.aspx As long as practitioners recognize that use case diagrams are optional and iconic (as opposed to schematic), they shouldn't have problems. The diagrams are useful, for example, on whiteboards as a way of sketching and framing an agenda while people are writing up and reviewing use case detail on index cards. The trouble starts, however, when projects end up with unreadable and overly complex use case diagrams. Those diagrams distract project members from the more useful endeavor of elaborating the use cases and result in wasted time. And the major value of the use case diagram -- showing the context of a software system -- ends up lost in a cloud of bubbles. Author: Kevlin Henney admin Sat, 03 Nov 2007 05:48:00 GMT f1397696-738c-4295-afcd-943feb885714:168 https://modernanalyst.com/Resources/Articles/tabid/115/ID/125/Use-Cases-Best-Practices.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=125 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=125&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/125/Use-Cases-Best-Practices.aspx A whitepaper written by requirements expert Ellen Gottesdiener of EBG Consulting (www.ebgconsulting.com) for IBM/Rational Software. As an analyst, you have the crucial task of defining the requirements for software that is to be built or acquired. Your task is crucial for a number of reasons. If software teams fail to define excellent requirements, projects suffer from a variety of problems, including quality shortfalls, failure to meet schedules, ever-expanding user requirements, and, in the end, customer dissatisfaction. The financial costs are enormous. Depending on which study you read, typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements. Whether you are defining requirements for new software, software that will be purchased, or existing software to be enhanced or maintained, it’s easy to see why a clear understanding of requirements is one of the most important determiners of project success. Moreover, the task of defining high-quality requirements is crucial to all the project stakeholders: clients, end users, developers, testers, and managers. Years of experience in defining requirements have led to the development of a number of techniques and models to assist in the process. Among these, perhaps the most well-known model is the use case, the focus of this paper. If you have experience with use cases, you know how pivotal they are for supporting many project activities, and you may be wondering how to improve your use case modeling to save time and energy. If you are new to use cases, you want to know the bottom line best practices for getting started. This paper’s goal is to provide practical advice to both novice and experienced use case modelers. Author: Ellen Gottesdiener ellengott Sat, 29 Sep 2007 18:32:00 GMT f1397696-738c-4295-afcd-943feb885714:125 https://modernanalyst.com/Resources/Articles/tabid/115/ID/124/Abuse-Case-Guidelines.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=124 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=124&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/124/Abuse-Case-Guidelines.aspx A set of 25 serious (and somewhat cynical) guides for abusing use cases by requirements expert Ellen Gottesdiener, of EBG Consulting, Inc. (www.ebgconsulting.com). Author: Ellen Gottesdiener ellengott Sat, 29 Sep 2007 18:09:00 GMT f1397696-738c-4295-afcd-943feb885714:124 https://modernanalyst.com/Resources/Articles/tabid/115/ID/123/The-Pros-and-Cons-of-Use-Case-Diagrams.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=123 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=123&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/123/The-Pros-and-Cons-of-Use-Case-Diagrams.aspx In the Unified Modeling Language (UML), use cases are visually represented as ellipses. However, in spite of its popularity and size, UML has little of practical use to offer modelers beyond this simple iconic representation. Trying to capture and present requirements using just use case diagrams can often render the otherwise useful technique of use cases almost useless. Practitioners are often drawn to expressing their intent by overworking the limited use case diagram notation, losing readers in a myriad of bubbles muddled together with obscure relationships and microscopic text. This article takes a step back to examine the pitfalls and recommend a more balanced and restrained approach. Author: Kevlin Henney cadams5 Sat, 29 Sep 2007 17:46:00 GMT f1397696-738c-4295-afcd-943feb885714:123 https://modernanalyst.com/Resources/Articles/tabid/115/ID/86/Debating-Use-Cases-and-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=86 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=86&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/86/Debating-Use-Cases-and-Requirements.aspx Read about the lively Use Case Panel: Discussion Among the Gurus - a panel held at the 2002 Rational Users Conference. "Doug Rosenberg wouldn't have a 20-page use case. Ian Spence would. But, as Ellen Gottesdiener reminded the panel, it's not all about size. Welcome to the Use Case Panel: Discussion Among Use Case Gurus. And what a panel it was. On hand for the Wednesday RUC 2002 event were Ivar Jacobson and Ian Spence from Rational Software, Ellen Gottesdiener from EBG Consulting, Inc., Doug Rosenberg from ICONIX Software, Elemer Magaziner from Project Linguistics, Intl., and Steve Adolph, from WSA Consulting, Inc. If any of the lightning flashing around Orlando today were to have stuck this room, there'd be no one left to write articles about use cases. The panel responded to questions submitted earlier in the week via the Rational public site and the Rational Developer Network. And, as you would expect, there was some agreement, a few disagreements, and an occasional debate, all of it ably moderated by Kurt Bittner from Rational." Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:32:00 GMT f1397696-738c-4295-afcd-943feb885714:86 https://modernanalyst.com/Resources/Articles/tabid/115/ID/85/Use-Cases-Best-Practices.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=85 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=85&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/85/Use-Cases-Best-Practices.aspx Years of experience in defining requirements have led to the development of a number of techniques and models to assist in the process. Among these, perhaps the most well-known model is the use case, the focus of this paper. If you have experience with use cases, you know how pivotal they are for supporting many project activities, and you may be wondering how to improve your use case modeling to save time and energy. If you are new to use cases, you want to know the bottom line best practices for getting started. In this white paper, requirements expert Ellen Gottesdiener of EBG Consulting provides practical advice to both novice and experienced use case modelers.  Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:25:00 GMT f1397696-738c-4295-afcd-943feb885714:85 https://modernanalyst.com/Resources/Articles/tabid/115/ID/84/Collaborate-for-Quality-Using-Workshops-to-Determine-Your-Projects-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=84 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=84&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/84/Collaborate-for-Quality-Using-Workshops-to-Determine-Your-Projects-Requirements.aspx Just how important is it to fully develop your project’s requirements? After all, nailing down your requirements usually takes only 8% to 15% of your overall project effort. Truth be told, it’s not really something you’ll want to spend your resources and energy on—unless, that is, you care at all about the quality of your product, your customers’ level of satisfaction, and the amount of post-implementation repair you’ll have to take care of down the road. Why is it so important to get requirements right? For one thing, you’re likely to introduce more defects into your software product in the requirements phase than in any other phase—and these defects account for as much as half of the product’s total defects. Defects originating in requirements are harder to remove than defects originating in any other phase. But that’s not all. Fixing them later in the project will cost you more, too—as much as 100 times more after implementation than if you detected and corrected them in the requirements phase. It’s no wonder that rework due to requirements defects can eat up as much as 50% of your overall budget. One other aspect of low-quality requirements is harder to measure, but just as treacherous. It’s called “scope creep,” and it’s cited as the most vexing problem in software development. Unrestrained by carefully developed requirements and mutual IT-customer or product development agreement, the scope of the project keeps creeping—expanding as the work proceeds. For all these reasons, project teams are searching for ways to develop requirements that are as free from defects as possible. One way to develop high-quality requirements is based on the use of collaborative workshops along with walkthroughs and QA checklists. As this article will illustrate, that combination of best practices gives you a powerful and efficient way to deliver quality user requirements—and, by extension, quality software products. Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:13:00 GMT f1397696-738c-4295-afcd-943feb885714:84 https://modernanalyst.com/Resources/Articles/tabid/115/ID/52/Validated-requirements-from-business-use-cases-and-the-Rational-Unified-Process.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=52 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=52&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/52/Validated-requirements-from-business-use-cases-and-the-Rational-Unified-Process.aspx Effective communication among application development project stakeholders is often challenging, especially when the team is geographically distributed or time constrained. IBM® Rational® software helps organizations automate, integrate, and govern the core business process of software and systems delivery via the IBM Rational Software Delivery Platform. At the platform's core is the IBM Rational Unified Process® (RUP®), a flexible framework for establishing an iterative business process for software and systems delivery. Based on more than two decades of harvested best practices, RUP helps to reduce the risk of project failure and promotes consistency, predictability, productivity, and efficiency across the organization. The RUP Business Modeling discipline provides tools and notations for business use cases which facilitate effective stakeholder communication and validation with domain experts. It allows business analysts to use the same notation and tools to document business processes that software architects and designers use to document software solutions. This allows the two groups to communicate better, ensuring that software systems really meet business needs. Read how business use cases can serve as the basis for validating requirements during the software development process.Author: Adam Frankl adrian Thu, 16 Aug 2007 03:27:00 GMT f1397696-738c-4295-afcd-943feb885714:52 https://modernanalyst.com/Resources/Articles/tabid/115/ID/127/How-to-Document-Use-Cases.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=127 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=127&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/127/How-to-Document-Use-Cases.aspx A use case represents a case of use of a system, ideally one that captures a functional requirement in terms of an identifiable and testable goal. So, what is the best way to document a use case? Approaches to content range from diagrammatic to textual, formal to free form, expansive and detailed to brief and abstract. The approaches to tool usage and authoring are just as varied. Here are some suggestions for a simple and streamlined, yet reasoned and thorough, approach to use case documentation. Author: Kevlin Henney adrian Sun, 29 Jul 2007 21:36:00 GMT f1397696-738c-4295-afcd-943feb885714:127 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3/Alternatives-of-Alternatives.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3/Alternatives-of-Alternatives.aspx Geri Schneider Winters writes about whether or not you could write alternatives to alternatives in use cases. There is no actual standard for the formatting of a use case specification, just guidelines and best practices.  Therefore, if using alternatives to alternatives in use cases makes the use case more clear - use it, by any means. Author: Geri Schneider Winters admin Tue, 17 Jul 2007 03:32:00 GMT f1397696-738c-4295-afcd-943feb885714:3 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4/Use-Cases-and-Reports.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=4 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=4&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4/Use-Cases-and-Reports.aspx In this article, Geri Schneider Winters discusses the question of whether use cases can be used to document requirements for reports. Author: Geri Schneider Winters admin Tue, 10 Jul 2007 03:39:00 GMT f1397696-738c-4295-afcd-943feb885714:4 https://modernanalyst.com/Resources/Articles/tabid/115/ID/68/The-Use-Case-Model.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=68 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=68&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/68/The-Use-Case-Model.aspx The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour. Author: Sparx Systems admin Tue, 17 Apr 2007 21:35:00 GMT f1397696-738c-4295-afcd-943feb885714:68